IBIS Macromodel Task Group Meeting date: 15 February 2022 Members (asterisk for those attending): Achronix Semiconductor: * Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma * Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao Majid Ahadi Dolatsara Ming Yan Radek Biernacki * Rui Yang Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): * Walter Katz Mike LaBonte Micron Technology: * Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Arpad to submit BIRD211.4 to the Open Forum. - Done. - Walter to send out BIRD213.1 draft 12 incorporating the meeting's changes. - Done -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the February 8th meeting. Ambrish moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: Specifying FEXT and NEXT in the impulse_matrix for statistical flow: Hansel shared a slide detailing his question/proposal. It noted that in IEEE 802.3ck, the COM tool only applies TXLE to the through-channel and FEXT responses. It does not apply TXLE to NEXT. Hansel observed the IBIS currently does not categorize the types of crosstalk in the crosstalk rows of the impulse_matrix parameter of AMI_Init. He asked whether we should change the specification to state that the rows of the impulse_matrix contain the through-channel response first, followed by FEXT responses, and then followed by NEXT responses. Wei-hsing said this would also require some way to indicate how many rows were FEXT and therefore how many were NEXT. Fangyi observed that this proposal would also interact with the newly submitted BIRD211.4, AMI Reference Flow Improvements. Walter said that the fact that the 802.3ck COM specifies that Tx equalization only applies to FEXT has nothing to do with NEXT and FEXT in our world. He said in the 802.3 standards the definition of FEXT was narrower, and it referred to aggressor and victim signals traveling from identical transmitters on the same chip to identical receivers on a single chip. Everything else is classified as NEXT. He said this has nothing to do with what an Rx must do when it's getting crosstalk contributions from all sources. Therefore, the AMI Rx must apply its equalization equally to all contributions. Walter said if an EDA tool were to want to employ special processing based on the IEEE standards' definition of FEXT and NEXT, it was free to exclude Tx equalization from transmitters on NEXT channels, likely because it didn't know the settings. FEXT aggressor channels, on the other hand, have identical settings to the primary channel. Walter said COM excluding Tx equalization for the NEXT terms was simply a case of COM wanting to be conservative. FEXT terms can be handled specially because of the specific definition of FEXT, and for all the NEXT terms the conservative approach is to apply no equalization to the NEXT channels. Arpad asked why we would care about this if it's specific to COM. Michael asked if there's a scenario where the IBIS 7.1 interpretation of the impulse_matrix is a problem. Fangyi asked the rhetorical question, "In the physical device, how could the Tx apply a certain equalization to just one component of the cross talk and not the other?" Walter agreed that it could not and does not. Fangyi said if it's physical behavior of the device, then it's our problem. If not, then it's not our problem. Walter said COM was developed by Richard Mellitz as a "cheap", no simulator way to get a SNR figure of merit at the decision point. Walter and Fangyi said COM uses generic equalization and prescribed optimization algorithms. AMI can model specific devices, noise, jitter, etc., that COM doesn't handle. Wei noted that eye width and eye height metrics were added to COM 2.95. Wei, Walter, and Fangyi said the tool and user could decide if they wanted to disable the Tx equalization for certain devices. The group consensus was that no changes to AMI are needed at this time. BIRD213.1 draft 12, PAMn: Walter shared draft 12. He recalled that in the previous meeting we had decided to remove this sentence on page 288, which Arpad had pointed out was ambiguous and confusing: ... it is assumed that the electrical interface to either the driver or the receiver is differential and will have ... To resolve Arpad's issue, we had first decided to change it to the following: ... it is assumed that the electrical interface to both the driver and receiver is differential and will have ... Then we had removed the entire sentence. Walter said that on further review he thought we needed to restore the sentence to introduce the possibility of more than 2 levels, which was discussed in the following paragraph. Walter also copied the preceding paragraph into both the "replace" and "with" sections to provide more context to the proposed change. Fangyi proposed some cleanup to the language in the Other Notes for PAM_Offsets describing the sampling time of the kth eye. Walter made the changes. Walter recalled that Ambrish had suggested that instead of Tables we use String Type parameters whose values are space delimited lists of numbers for PAM_Offsets and PAM_Thresholds. Ambrish agreed that this was his suggestion. Walter said he had no strong objection to this. He said they had used the same technique in Model Specific parameters in the past, for example to return poles and residues in peaking filters. However, he thought the preferred IBIS solution would be to use a Table. Walter said he would send out a draft 13. - Ambrish: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Walter to send out BIRD213.1 draft 13 incorporating today's changes. ------------- Next meeting: 22 February 2022 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives